home *** CD-ROM | disk | FTP | other *** search
- Network Working Group Michael Beeler (BBN-TENEX)
- Request for Comments: 685 April 16, 1975
- NIC #32298
-
-
- Response Time in Cross-network Debugging
-
-
-
- Cross-network debugging is a means whereby a programmer at one
- computer on a network can debug a program which executes on another
- computer. One form of cross-net debugging has been in use for some
- years by programmers who maintain IMPs on the ARPA network. Another
- form has been used by ARPA network users who employ TELNET or RSEXEC
- to log into a distant computer and remotely run a debugger on that
- machine. In both of these cases, the debugger is almost entirely
- resident in the same machine as the subject program, and only a
- remote means of access to that computer distinguishes the activity
- from single-computer debugging.
-
- In our case, we use a PDP-10 to perform complex debugging
- manipulations. Simple manipulations, and complex actions which the
- PDP-10 has partially digested into simple actions, are sent over the
- ARPA network to a PDP-11. The portion of the debugger resident in
- the PDP-11, where the subject program executes, can perform only
- simple actions (examine, deposit, start, stop, set breakpoint,
- etc.). This division of debugging computation between the two
- machines is implemented and in use at BBN. A user s manual is
- available (as (BBN]<DOCUMENTATION>XNET.DOC) describing the
- debugger s features and discussing some of the issues involved.
-
- The purpose of this RFC is to describe our experience with
- response times the debugger exhibits. Response time is a serious
- problem in any elaboration to a debugger. Here we wish to discuss
- the contribution of communicating over the ARPA network to response
- time. The debugger (X-NET) keeps statistics during each debugging
- session, and a debugger command prints them out. We used a
- "standard scenario" to measure response times on two occasions. The
- first was debugging a PDP-11 at BBN on the same IMP as the PDP-10.
- The second was with a PDP-11 at SRI-ARC in California, with at least
- nine IMPs intervening.
-
- BBN (local) SRI (distant)
- TENEX LOAD AVG
- START 6.0 4.65
- FINISH 3.9 6.6
- TIME OF DAY 15:30 EST 11:00 EST
- DAY 4/10/75
- 4/11/75
-
- Page 2
-
-
- Each session lasted about 10 minutes. The terms used below
- are:
-
- message -- a single message generated by the PDP-10 portion of X-NET
-
- active command -- a command which involves, actually or virtually,
- an interaction with the subject program (e.g., examine, deposit,
- start, stop, set breakpoint, etc.)
-
- bytes -- the total of all (8-bit) bytes, both sent and received,
- plus any bytes due to receipt of asynchronous replies (e.g.,
- breakpoint hit), during processing of the associated message or
- active command.
-
- wait -- total elapsed time from handing message to implementation
- language (BCPL) network routines, to receipt of the reply from
- these routines and through an inferior process in X-NET
-
- The 35 active commands in the scenario are:
-
- 1 load program
- 8 start or proceed program
- 3 halt program
- 16 examine contents of memory word
- 1 deposit new contents in memory word
- 1 set breakpoint
- 1 remove breakpoint
- 1 word search
- 1 copy program onto disk file
- 2 network/process management (see user's manual)
-
- The summary statistics are:.
-
- BBN (local) SRI (distant)
- AVG STD DEV AVG STD DEV
- PER MESSAGE:
- BYTES 154 295 164 295
- WAIT 1.75 2.04 1.89 0.78 SEC
- PER ACTIVE COMMAND:
- MSGS 0.91 0.69 0.91 0.69
- BYTES 150 331 150 331
- WAIT 1.60 2.36 1.73 1.35 SEC
-
- The standard deviation is relatively large partly because of a
- small number of samples, but even more because the message size and
- the command complexity are bimodal, as shown by the histograms
- below. The load and word search commands transferred many bytes, as
- did an examine (the first one while the program was halted;
- subsequent examines were answerable from the cache; see user s
- manual). Other commands needed little or no network transaction.
- Those which needed none at all produced a no-delay mode in the
- distribution of waiting time per active command.
-
- Page 3
-
-
- We conclude that the delay due to network communication is
- tolerable. It is of the same order of magnitude as that often
- experienced on moderately loaded time sharing systems. More
- explicit measurements of delays seen by user programs in general are
- in progress at BBN and elsewhere; it is beyond the scope of this RFC
- to discuss these delays in detail, or to break down their causes
- into process activation, queueing, IMP performance, etc. Instead,
- we merely note that cross-network debugging is possible in a
- practical sense.
-
- PER MESSAGE PER ACTIVE COMMAND
- 0 . XXXXXXXXX
- 16 . .
- 32 XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX
- 64 . XXX
- 128 . .
- 256 XX .
- 512 XXXX XX
- 1024 . XX
-
- SIZE (BYTES), BBN (local data) = SRI (distant data) Left column
- gives lower bound (inclusive) on logarithmic scale. Thus, two
- messages had at least 256 bytes but less than 512 bytes. An
- examination of network traffic per active command shows that it is
- actually trimodal: some commands are answered from the cache,
- incurring no network traffic; some, such as start or stop, require
- only a few tens of bytes; and some commands, such as word search and
- load, cause transfer of thousands of bytes.
-
-
-
- PER MESSAGE PER ACTIVE COMMAND
- 0 . XXXXXXXXX
- 1/16 X .
- 1/8 . .
- 1/4 X .
- 1/2 XXXXXXXXXX XXXXXXXX
- 1 XXXXXXXXXXXXXX XXXXXXXXXXX
- 2 XXXX XXXX
- 4 X X
- 8 X XX
-
- WAITING TIME (SEC), BBN (local data)
-
- Page 4
-
-
-
-
- PER MESSAGE PER ACTIVE COMMAND
- 0 . XXXXXXXXX
- 1/16 . .
- 1/8 . .
- 1/4 X .
- 1/2 XXXXXX XXX
- 1 XXXXXXXXXXXX XXXXXXXXX
- 2 XXXXXXXXXXXXX XXXXXXXXXXXX
- 4 . XX
- 8 . .
-
- WAITING TIME (SEC), SRI (distant data)
-